IBIS Macromodel Task Group

Meeting date: 15 September 2020

Members (asterisk for those attending):
Achronix Semiconductor      * Hansel Dsilva
ANSYS:                      * Curtis Clark
                            * Wei-hsing Huang
Cadence Design Systems:       Ambrish Varma
                              Ken Willis
                            * Jared James
Google:                     * Zhiping Yang
Intel:                      * Michael Mirmak
                            * Kinger Cai
Keysight Technologies:      * Fangyi Rao
                            * Radek Biernacki
                              Ming Yan
                              Todd Bermensolo
                            * Rui Yang
Marvell                       Steve Parker
Mentor, A Siemens Business: * Arpad Muranyi
Micron Technology:          * Randy Wolff
                            * Justin Butterfield
SiSoft (Mathworks):         * Walter Katz
                              Mike LaBonte
Teraspeed Labs:             * Bob Ross
Zuken USA:                    Lance Wang

The meeting was led by Arpad Muranyi.  Curtis Clark took the minutes.

--------------------------------------------------------------------------------
Opens:

- None.

-------------
Review of ARs:

- None.
  
--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

Arpad asked for any comments or corrections to the minutes of the September 01
meeting.  Michael moved to approve the minutes.  Randy seconded the motion.
There were no objections.

-------------
New Discussion:

Standard Power Integrity Model (SPIM) with Unified PI Target (UPIT):
Kinger Cai reviewed this presentation, which was given at the 2020 IEEE
EMC+SIPI Symposium IBIS Summit on August 28th, 2020.
- The presentation can be found here: https://urldefense.proofpoint.com/v2/url?u=https-3A__ibis.org_summits_aug20&d=DwIGAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=DcQR-qLpQg5lIreuM6-NYECRIAFXt268PRNS5WO043M&m=zQoyurGPNZu5UZFRusr4oBu7YULxaA2oszaJ3DTwXnU&s=sYjhAvmEVqiK5mzz7Hts5GvxOrjBN-9OBe8hHwbQ6Sw&e= 
- Summit Minutes including discussion of the presentation can be found here:
  https://urldefense.proofpoint.com/v2/url?u=https-3A__ibis.org_minutes_min2020_m082820.pdf&d=DwIGAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=DcQR-qLpQg5lIreuM6-NYECRIAFXt268PRNS5WO043M&m=zQoyurGPNZu5UZFRusr4oBu7YULxaA2oszaJ3DTwXnU&s=-vvK9t5FkYsIEyd56DdOeqE-Rw63A2zRy7etBdqpKS4&e= 
  
Kinger described FastPI as a design methodology targeted for platform (board
level) PI design.  It is based on the chip vendor providing SPIM and UPIT
information to their customers the platform designers.  The goal is to provide
sufficient information to the platform designers while protecting vendor IP.
He noted that SPIM and UPIT have been part of the standard PI collateral Intel
provides to system designers for five years.  It is similar in concept to IBIS,
which was originally developed by Intel for similar purposes for SI designers.
  
Additional details, beyond those discussed at the Summit and captured in the
summit minutes, are recorded here.

Zhiping noted that the goals of SPIM (slide 5) parallel the original development
of IBIS for SI design.

Kinger noted that the UPIT makes the process scalable, as different UPITs could
be provided, for example, for different cost/performance variants based on the
same SPIM.

Arpad referred to the IBIS syntax mockup on slide 13.  He asked if the goal was
to incorporate this new syntax into IBIS or develop a stand-alone specification.
Kinger said he didn't have a strong preference.  He expected to broadly follow
traditional IBIS syntax.  However, since there might not be a lot of interaction
between this proposal and SI IBIS simulations, it might be easier to create a
stand-alone specification.  Arpad, however, noted that the example on slide 13
utilized pin lists and other things that are already included in IBIS.  This
proposal is related to the chip/die and could be folded into IBIS since the power
and ground pins already exist in IBIS.  Randy agreed that we have the capability
to carry some of this information in our package modeling.  Walter said the
S-parameter portion of the SPIM should work fine with the rail modeling in our
package and EMD modeling.  Kinger noted that the SPIM model includes additional
information.  Randy said it would be helpful to see more detail about the
stimulus sources and how they're defined, as this might be what we need to
work on standardizing and linking into IBIS.  Bob and Zhiping also preferred
linking the proposal into existing IBIS, and Bob noted that the example on 
slide 13 implicitly relies on other keywords such as Pin Mapping.

Arpad asked if Kinger could review existing IBIS 7.0 interconnect syntax and see
how it fit with his proposal.  Kinger said he would look into IBIS 7.0 and work
with Michael on possible proposals.

New Clock-Data Pin relationship BIRD [Clock Pins]:
Michael Mirmak briefly reviewed the Clock Pins BIRD draft he had sent to ATM the
day before the meeting.  It is intended to address DDR issues.  He noted that we
have BIRD204, which enable data buffers to accept external clocking inputs, and
BIRD207, which allows the executable model to be passed the Component and
signal_name of the pin it is simulating.  Michael said that nothing yet defines
the clocking relationship between any two pins.  He said we can't really define
that relationship at the .ami level, as it's the [Pin List] that typically
controls what the user wants to instantiate.  He noted that different pins might
have different relationships.  You might have one buffer pin that uses one clock
pin, or you might have 4 pins that use the same clock pin, etc.  This clock-data
relationship should be defined at the same level as the [Pin List].

The BIRD defines a new keyword [Clock Pins] at [Component] scope.  Each entry
contains three columns.  The first column is the name of a clock Pin, the second
is the name of an associated data Pin, and the third column specifies the timing
relationship between the two.  Valid values for column 3 are: Clock_Skew,
Clock_to_Out, or Setup_Hold.  Michael noted that he had intentionally not
provided exhaustive definitions of the timing relationships.  He said that for
the time being they are little more than glorified comments.  He said his
concern was that hashing out the details of the timing relationships will be a
lengthy process, and he said it could be the subject of an additional BIRD.
Specifying the clock-pin data-pin relationship is an immediate need, and it's
important not to have this BIRD delayed while the details of column three are
worked out.

Randy noted that the term "pin_name" should be used when referring to pin name
entries from the [Pin List], to be consistent with other sections.  Michael
agreed and noted the change.  Randy said the meaning of the three proposed
values in column three were not clear to him.  Fangyi also said that he would
prefer to see some more details on the column three values.  Michael took an AR
to send out a second version incorporating some of the feedback from the meeting
and email.

- Randy: Motion to adjourn.
- Curtis: Second.
- Arpad: Thank you all for joining.

AR: Michael to send a second draft of the [Clock Pins] BIRD proposal.

-------------
Next meeting: 22 September 2020 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
